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The complexiry of configuring every dement in the network— clients, 
servers, peers, and infrastructure — is a key problem racing network 
technology's advance. As long as configuration remains difficult, net- 
work administration will be expensive; tedious, and troublesome, and users 
will be unable to take advantage of the full range of capabilities networked 
systems could provide The Service Location Protocol' is an Internet Engi- 
neering Task Force standard for enabling network- based applications to 
automatically discover the location — including address or domain name 
and other configuration information— of a required service. Client* can 
connect to and make use of services using SLR Currently, without SLP, 
service locations must be manually configured or entered into a configu- 
ration file. SLP provides for fully decentralized operation and scales from 
small, unadministered networks to large enterprise networks with policies 
dictating who can discover which resources. 

This article describes SLP s operation and how it adapts co conditions 
where infrastructure is not available, where administration is minimal, or 
where network administrators simply wish to reduce workload. 

BACKGROUND 

The Service Location Protocol (SVRLOQ working group has been active 
in the IETF for several years. In 1997, the group published SLP Version 1 
as a Proposed Standard RFC 1 In June 1 999, the Internet Engineering Steer- 
ing Group announced that Version 2 and its related documents were pro- 
moted to Proposed Standard RFCs as well. 2 SLPv2, which updates and 
replaces SUM, is the subject of this article. It removes several of the orig- 
inally imposed requirements, provides protocol extensibility (new options 
can be added without modifying the base protocol), adheres to new IESG 
protocol recommendations, improves security, and eliminates a number of 
inconsistencies in the SUM specification. 




As computers become more 
portable and networks larger 
and more pervasive, the 
need to automate the location 
and dient 
configuration for 
network services also 
increases. The Service Location 
Protocol is an IETF standard 
that provides a scalable 
framework for automatic 
resource discovery on IP 
networks. 
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Figure 1 . Methods of DA discovery. In active discovery, User 
Agents and Service Agents multicast requests to locate Directory 
Agents on the network, whereas, in passive discovery, UAs and 
SAs loom of DAs via periodic multicast advisements. 



Backward compatibility with SLPvl depends on 
whether the Directory Agent (described in rhe next 
section) supports both versions. For example. Sun 
has successful]/ implemented a backwardly com- 
patible SLP DA. Otherwise, backward comparabil- 
ity requires a Service Agent (also described below) 
to implement both versions of the protocol. 

Problems with Earlier Protocols 

Prior to SLP, service discovery protocols allowed 
users to discover services only by type. For instance, 
both Apple and Microsoft offered networking pro- 
tocols that could discover instances of printers and 
file servers, and users had to then select from the 
list to meet their needs. From the beginning, the 
SVRLOC working group sought a solution that 
would allow network software to discover services 
according to their characteristics as well as type. 
Thus, clients would be able to explicitly discover 
services that met their requirements, and software 
could automatically obtain the service location 
without bothering users. 

On the other hand, since services axe advertised 
along with their characteristics, SLP also enables 
rich user interaction. SLP enables browser opera- 
tions since the protocol includes a set of directory- 
like functions. Thus, clients using SLP can browse 
all the available types of service. These clients may 
also request the attributes of a class of service, which 
aids in formulating interactive requests. Finally, 
SLP makes it possible to look up the attributes of 
a particular service once it has been discovered. 

Another problem with the proprietary protocols 
was their notorious lack of scalability. The 



5RVLOC working group sought to correct this 
problem by minimizing the impact of service dis- 
covery on the network. SLP uses multicast and 
Dynamic Host Configuration Protocol 3 to initial- 
ize its scalable service discovery framework without 
the need for configuring individual SLP agents. 
SLP can operate in networks ranging from a single 
LAN to a network under a common administra- 
tion, also known as an enterprise network. These 
networks can be quite large (potentially tens of 
thousands of networked devices). Neither multi- 
cast discovery nor DHCP scales to the Internet, 
since these protocols must be configured and 
administered. Moreover, the Internet lacks a com- 
mon centralized administration. To the extent that 
SLP relies on either multicast discovery or DHCP 
for its own configuration, SLP does not scale to the 
Internet. 

Current SLP Implementations 

Sun Microsystems, Novell, IBM, Apple, Axis Com- 
munications, Lexmark, Madison River Technolo- 
gies, and Hewlett-Packard have adopted SLPvl, 
and, increasingly, SLPv2 for products. There are also 
two reference implementations of SLPv2 available 
from http://www.srvloc.org/. 

PROTOCOL OVERVIEW 

SLP establishes a framework for resource discovery 
that includes three "agents" that operate on behalf 
of the ncrwork-based software: 

■ User Agents (UA) perform service discovery on 
behalf of client software. 

■ Service Agents (SA) advertise the location and 
attributes on behalf of services. 

■ Directory Agents (DA) aggregate service infor- 
mation into what is initially a stateless 
repository. 

Figure 1 illustrates the two different methods for 
DA discovery: active and passive. In active discov- 
ery, UAs and SAs multicast SLP requests to the net- 
work. In passive discovery, DAs multicast adver- 
tisements for their services and continue to do this 
periodically in case any UAs or SAs have failed to 
receive the initial advertisement. 

UAs and SAs can also learn the locations of DAs 
by using the DHCP options for Service Location, 
SLP DA Option (78). 4 DHCP servers, configured 
by network administrators, can use DHCP Option 
78 to distribute the addresses of DAs to hosts that 
request them. SLP agents configured in this man- 
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ner do nor require the use of multicast discovery, 
since this is only used to discover DAs and to dis- 
cover services in the absence of DAs. 



Operational Modes 

5 LP has two modes of operation: 

■ When a DA is present, it collects ail service 
information advertised by SAs, and UAs uni- 
casr their requests ro the DA. 

■ In the absence of a DA. UAs repeatedly multi- 
cast the same request they would have unicasr 
to a DA. SAs listen for these multicast requests 
and unicasr responses to the UA if it has adver- 
tised the requested service. 

When a DA is present. UAs receive faster respons- 
es, SLP uses less network bandwidth, and fewer (or 
zero) multicast messages are issued. 

Aside from unsolicited announcements sent by 
DAs, all messages in SLP are requests that elicit 
responses. By default, SLP agents send all messages 
in UDP datagrams; TCP is used only to send mes- 
sages that don't fit in a single datagram. 

Service Advertisements 

Services are advertised using a Service URL, which 
contains the services location: the IP address, port 
number and, depending on the service type, path. 
Client applications that obtain this URL have all 
the information they need to connect to the adver- 
tised service. The actual protocol the client uses to 
communicate with the service is independent of 
SLP 

Service Templates' — documents registered with 
the Internet Assigned Numbers Authority 
(IANA) — define the attributes associated with ser- 
vice advertisements. Templates specify the attrib- 
utes, and their default values and interpretation, 
for a particular service type. SAs advertise services 
according to attribute definitions in the Service 
Templates, and UAs issue requests using these same 
definitions. This ensures interoperablility between 
vendors because every client will request services 
using the same vocabulary, and every service will 
advertise itself using well-known attributes. 

OPERATIONS AND SCENARIOS 

SLP operates in several different scenarios. 
Initialization 

At startup, UAs and SAs first determine whether 
there are any DAs on the network. DA addre 



In SIP, User Agents ond Service Agents can use the mufti cost con- 
vergence algorithm so discover Directory Agents. UAs can also use 
it to issue requests when no OA is present. This algorithm allows 
SIP agents to receive rep/ ies from more responders than they could 
with standard multicast. Ordinarily in multicast, if there are many 
responders, a requester is likefy to be inundated by the implosion 
of responses. 

The SLP agent attempting to discover services (or DAs) issues 
an SLP Service Request message using multicast. This may result 
in one or more unicast response messages. After a woit period, 
the request is reissued with an appended 'previous responders 
list/ including the odd r ess of each SLP agent that has already 
responded. When SAs or DAs receive requests, they first examine 
the previous responded list, if they discover themselves on the list, 
they do not respond to the request. 

The previous responder list can contain about 60-100 entries 
before it, combined with the request, becomes too large to fit in 
the request datagram. Reliable multicast is a notoriously difficult 
problem, but SIP'S multicast convergence algorithm provides a 
"semi-reliable" multicast transaction. 

Figure A illustrates the algorithm's operation as used in DA 
discovery. When the request is first sent, DAs 1 , 2, and 3 reply, 
but the reply from DA 3 is lost. When the request is retransmitted 
o second rime, DAs 1 ond 2 do not respond, but since DA 3 is 
not yet on the list, it replies again. On the third retransmission 
no DAs respond since they all finally appear on the previous 
responders list. 




Service request 

)|PR listindudesDAi 1,2, and 3) 



Figure A. The multicast convergence algorithm in DA discovery. 
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Figure 2. Normal operation of SIP. The SA registers the overhead 
projection server's location with the DA, and in response to the 
UA's Service Request message, it obtains this location from the DA 
via a Service Reply message. 



can be configured statically (either manually con- 
figured, read from a configuration file, or hard- 
coded). DA locations can also be obtained dynam- 
ically using DHCP as discussed above. In these 
cases, there is no need to perform DA discovery. In 
all other cases, UAs and SA* use the SLP multicast 
convergence algorithm to discover DAs (see the 
sidebar, "SLP Multicast Convergence Algorithm*). 
They multicast Service Request messages to obtain 
DA advertisement messages, which include the Ser- 
vice URL 5 as well as the DAs scope, attributes, and 
digital signature. From this information UAs and 
SAs can locate the correct DA for message exchange. 

Standard Case 

Figure 2 depicts SLP's normal operation. In this 
example, a client program seeks an overhead pro- 
jection server to display a presentation to an assem- 
bled audience. The SA registers the services loca- 
tion with the DA, and the UA obtains this location 
from the DA in a Service Reply message. 

Note that the SLP agents depicted may or may not 
reside on separate networked computers, but only 
one DA or SA can be on any given machine, due to 
the rules of the multicast convergence algorithm. 

The networked service process advertises itself by 
registering with a DA, using an internal Service Loca- 
tion Protocol API. 6 An SA on the same computer as 
the network service registers service information by 
sending a Service Registration message to the DA and 
awaiting a Service Ackncwledgment in reply 

Service registrations have lifetimes no greater 
than 1 8 hours, so the SA must reregister the service 
periodically, or the lifetime expires. In the event 



that the service terminates, the SA can optionally 
send a Service Dercgister message to the DA; but 
even in the worst case, when the service fails, the 
registration will age out. This ensures that stale 
information will not persist with the DA 

Client software can use the standard Service Loca- 
tion Protocol API to find the particular service it 
requires. In this case, a UA sends the DA a Service 
Request that includes a search filter that is syntacti- 
cally identical to the request format used by version 
3 of oSe Lightweight Directory Access Protocol. 7 SLP 
thereby provides a directory-like lookup of all ser- 
vices that match the clients requirements. iTie DA 
returns a Service Reply message containing Service 
URLs and enough information for the client to con- 
tact each service that matches the request. 

Larger Network Environments 

A DA may serve thousands of clients and servers, 
so SLP gives administrators ways to improve over- 
all performance and scalability of an SLP deploy- 
ment as DAs become more loaded. 

More DAs. First of all, administrators can simply 
activate more DAs to enhance SLP performance. 
Because SAs register with each DA they detect, all 
DAs will eventually contain the same service infor- 
mation, provided that all SAs can rind them all. (Of 
course, sometimes this is neither possible nor desir- 
able.) Adding more DAs creates roughly duplicate 
repositories of service information without requir- 
ing any formal database synchronization between 
them. Moreover, since UAs can choose any avail- 
able DA to issue requests to, the load will be shared 
among DAs. Additional DAs also provide robust- 
ness in cases where one rails or becomes overloaded. 

Scope. The second mechanism for increasing SLP 
scalability is scope. A scope is a string used to group 
resources by location, network, or acbninisrrarjve cat- 
egory. SAs and UAs arc by default configured with 
the scope string 'default." Figure 3, for example, 
shows how a UA issuing requests in the legal depart- 
ment of an organization might find services within 
that scope, but not in accounts payable. (Note that 
services may be available in multiple scopes.) 

UAs can accumulate DA advertisements to form 
lists of all available scopes. When no DAs are pre- 
sent, UAs can multicast requests for SA advertise- 
ments to create lists of scopes supported by the SAs. 

DHCP. SLP agents (UAs, SAs. and DAs) can access 
non-default scopes via static configuration or 
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DHCP Option for Service Location, SLP Service 
Scope Option (79)/ Because it allows an adminis- 
trator to easily control the set of services available 
to a particular client. DHCP is actually the pre- 
ferred method for configuring SIP. For example, 
all services and clients in a hotel room could be 
configured to the scope of that one room. A laptop 
computer used in a particular room would discov- 
er only those services in the room itself Hotel 
guests could then locate printers in cheir own 
rooms, bur nor in others to which they have no 
physical access. 

Small Office or Home Networks 

When there is no directory agent, a'UA multicast; 
the same requests to the SAs that it would have 
unica>t to the DA. Thus, SAs must be prepared to 
answer Service Requests. A Service Request 
includes a query that the SA processes against the 
attributes of the services ir advertises. If the multi- 
cast request fails to match, or if the SA is unable to 
process it (due to an error in the request, for 
instance), the SA simply discards the request. 

I'he multicast convergence algorithm used for DA 
discovery is also used by UAs for service discovery. 

It is important to note that services can be dis- 
covered by clients using SIP in small nerworlcs 
without any SLP-speciftc configuration or the 
deployment of any additional services. SLP dis- 
covery works even in the absence of DNS, DHCP, 
SLP DAs, and routing. This makes SLP suitable for 
the home or small office environment, where 
impromptu and un administered networks would 
greatly benefit from automatic service discovery. 

FITTING THE PIECES TOGETHER 

SLP in icself. only provides a service discovery frame- 
work. Thai is,. SLP agents are idle until service soft- 
ware is advertised populating the SAs, which in turn 
propagate information to appropriate DAs. UAs are 
inactive until a client issues a specific request. 

The SLP API, however, allows applications and 
services to access SLP j functionality. Ir provides for 
both synchronous and asynchronous operations, 
and it features both C and Java bindings. (Table 1 
summarizes the C language bindings, and Figure 4 
summarizes the Java language bindings.) The API 
contains separate interfaces for client software to 
use for discovery and for server software to use for 
advertising; peer-io-peer software can use both por- 
tions. Figure 5 illustrates the interaction between a 
client and a service, the SLP API, and a UA and SA 
performing a Service Request opervnon. 




Figure 3. Scope in SLP. User Agents con only locate services within 
the scopes to which they have access. 



public interface Advertiser { 

public abstract void ragisterjServiceUKl url. Vector attributes}; 
public absfrocf void a«IaVkrrraKjfes(ServtceURi url Vector attributes); 
pubfic abstract void deietoAttnbiites (ServiceURL uH, Vector attributes); 

). 

public interface Locator ( 
public abstract Locale getLoeoleO; 
publk abstract Servtcetocoriortcnumerarion 

findSeJ-vicefypes(String naming Authority, Vector scope?) 
public abstract ServicelocotionEnurneration 
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public class SeJvfcetocationManaejer { 
public int getftefreshlnte)rval(); 
public static Vector find Scopesft; 
public static Advertiser getAdverti»ert); 
public static locator cjetLocatorf); 



Figure 4. SIP API Java bindings. 
Details 

SLP is a mostly string-based proroeol that uses a 
binary message header, as shown in Figure 6. Mes- 
sages are largely composed of UTF-8 strings 1 pre- 
ceded by length fields. (See Table 2 on page 79 for 
a description of other fields.) 

The SLP header concludes with a Language 
Tag. 9 Amibute value strings in the SLP message are 
translated into the language indicated by the tag, 
and the Service Template' associated with a partic- 
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Figure 5. Client server discovery using SLP without DAs. The client 
oppfcotion uses a UA to multicast o Service Request that the SA 
responds to with o un least Service Reply. 
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Figure 6. The SIP Header. The SIP header precedes and character- 
izes aD transmitted SLP messages. 



uiar service provides additional informed on regard- 
ing internationalization. Some strings have stan- 
dardized translations, while others have fixed mean- 
ings and are not intended to be translated. 

The Function ID Field indicates the SLP mes- 
sage type, all of which are summarized in Table 3 
(page 79). 

SLPs central function is the exchange of Service 
Request and Service Reply messages. A UA, for 



instance, only has to be able to send Service 
Requests (though it also needs co handle Service 
Replies and DA advertisements as a result of those 
requests). An SA need not support any fcarures 
besides discovering DAs. responding to Service 
Requests, and sending Service Registration mes- 
sages to appropriate DAs. 

Deployment 

Currently, service location information is acquired by 
prompting the user or reading It from a configura- 
tion file. To use SLP, client software vendors must 
modify the network configuration portions of the 
client to employ die SLP API 6 to obtain the location 
of the server. By modifying the failure notification 
path as well, automatic service discovery can be reini- 
tiated when a server fails. In this way, another server 
can be located without interrupting the users service. 

Alternatively, it is possible to utilize the benefits of 
SLP without modifying the client software, as long 
as the client already uses an existing service for con- 
figuration. For instance, some clients use the 
LDAIV3 protocol 10 to access a directory for config- 
uration information, so they can discover services that 
SLP has automatically registered with the directory. 

SLP attributes, Service Templates, and search fil- 
ters arc all compatible with a subset of LDAJV3. This 
means that services registered with an SLP DA can 
be automatically registered into an LDAPv3 direc- 
tory. That is, an LDAPv3 directory can function as 
the back end for an SLP DA. Thus, users of the 
LDAPv3 directory can obtain current network ser- 
vice information automatically. SLPs interoperabil- 
ity with LDAPv3 eases the integration of network 
configuration information in IP networks, where 
directories arc increasingly used to centralize access. 



Table 1 . SLP APt C lormuooe bindings, 
Binding 

SLPOpen 

SLPCIose 
SLPReg 



SLPDereg 

SlPOeJArtrs 

SLPfindSrvs 

SIPFindSrvTypes 
SLPfindAltrs 



Description 

Clients and services initialize the SLP library and obtain a handle to use with afl subsequent colls. 
Clients and services release the SLP library. 

Services register their service URL and attributes. A service may also use this interface to update its 
service attributes or refresh o registration before it expires. 
Services can deregister their availability. 
Services can deregister a particular attribute. 

Clients can obtain service URb based on their query by service type, SIP scope, and/or service attrib- 
utes. These URLs will, by definition, be the locations of services the client can use. 
Clients can discover oil types of service available on the network. 

Oients can cfiscover attributes of a porticulor service or tSe attributes of all services of o given service type. 
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There is o groat deal of work going on in the area of auto- 
configuration. Comparison with other approaches shows 
SIP'S generality and versatility. 

DHCP Service Options 

The location of several types of service can be configured 
using DHCP. Administrators can configure certain clients 
for a particular server. For example, DHCP option 42 con- 
figures a host to use a particular Network Time Protocol 
(KTPJ T server or servers. 

Using DHCP to configure services is significantly different 
from using SIP. DHCP servers, for instance, have no intrinsic 
way to determine whether on address actually refer* to a cur- 
rently available server. SLP, on the other hand, lets you dis- 
cover servers with known availability. SiP also allows a dient 
lo discover a server for meets its specific retirements. DHCP 
provides no such nriechonism. 

DNS Resource Records for Specifying the 
Location of Services 

The Domain Name System (DNS) SRV Resource Record 
(SR V RR) 2J allows for lookups of domain names associated 
with service names. Thus, a DNS revolver con request oil 
instances of o porticutor service type wtlhin o given domain. 

For example, to find al instances of TCP-based line printer 
(LPR) services in tSe domain 'nonexistertt.net/ a DNS resoker 
would send a request to the DNS SRV RR lor ftSe service named 
1pr.tcp.rianexistent.net." This might return two domain names: 
^ig.noneristent.net* and 'snKJ.rwiexis1ent.net.' 

Unlike operations in SLP, resolving a DNS SRV RR cur- 
rently requires o DNS server to be present. Woodcock and 
Manning currently have an effort underway to standardize 
o new mechanism to allow multicasting of DNS requests. 4 



According to this proposal, individual systems could contain 
"stub" DNS servers thot would respond to multicast requests 
in the absence of a true DNS server. This mecftanism would 
remove the requirement for a DNS server to be present, 
making the DNS SRV Rlcs approach suitable for small net- 
works lacking in administration and infrastructure. 

This service discovery method, however, allows the dient 
to discover services only by type, and not by service char- 
acteristics. 

There is currently no way to update DNS servers when ser- 
vices become available or go down; as with DHCP, the dient 
system might easily obtain locations for 

services that are not 

currently available. 

Simple Multicast Discovery Protocols 

A variety of simple multicast discovery protocols hove been 
proposed over the years. 57 In ad of them, a client multicast* 
a request for a desired service type. All available services 
that receive the multicast request send a response, includ- 
ing the location of services matching the type requested. 

Some of the proposals allow services to announce their 
presence as they come up and periodically thereafter, so 
clients can become immediately aware of new services. 
However, none of them scales beyond a small network. 
Unlike SLP, they provide no means for automatic service 
information collection. Moreover, they cannot detect that 
they are in a larger network and should slop multicasting 
or limit their TTl to ovoid disrupting operations. 

Finally, these protocols fail to include any features for reli- 
obie multicasting, if dozens of resfxmJers attempt lo reply to 
a multicast request, the implosion of replies may inundate 4te 
requester. SLP ameliorates this problem by using previous- 

continued on p. 78 



ADDITIONAL FEATURES 

The essential function of SLP is service discovery. 
SLP has also been designed ro provide security, 
extensibility, support for browsing operations, and 
operation over IPv6. These features extend chc util- 
ity of SLR and will be especially useful once a stan- 
dardized security infrastructure has been widely 
adopted on IP networks. 

Security 

SLP is designed ro make service information avail- 
able, and it contains no mechanisms to restrict 
access to this in/ormarion. Irs only security prop- 
erty is authentication of the source of information, 



which prevents SLP from being used co malicious- 
ly propagate false information about the location 
of services. 

Digital signatures. An SA can include a digital sig- 
nature produced with public key cryptography 
along with its registration messages. A DA can 
then verify the signature before registering or 
deregistertng any service information on the SAs 
behalf. These digital signatures are then forward- 
ed in reply messages to UAs. so they can reject 
unsigned or incorrectly signed service information. 
Of course, DAs and UAs can only verify signa- 
tures, not produce them. 
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continued from p. 77 

respond* lists in ih multicast convergence algorithm (as cSs- 
cussed in the sidebar). Of course, ihe replies could be stag- 
gered by requiring responded to woit for a random interval, 
but this would force the requester to wait much longer for 
answers where there are Few results. 

Jini 

Sun Microsystems' Jini technology provides a Java-oriented 
set of mechanisms and programmer interfaces for automat- 
ic configuration. As an IETF standard, SIP is a general mech- 
anism suited to heterogeneous systems. Jini, on the other 
horxJ, leverages Java's uniformity across platforms, provid- 
ing powerful semantics for service discovery operations. 

The Jini discovery architecture is similar to that of SIP. Jini 
agents discover the existence of a Jin! lookup Server, which 
collects service advertisements in a manner analogous to 
DAs in SIP. Jini agents then request services on behalf of 
diertt software by communicating with the Lookup Server. 
Unlike SLP, however, where DAs are optional Jini requires 
the presence of one or more Lookup Servers. 

Jini's discovery mechanism offers some advantages to 
Java-based clients. The Lookup Server uses object-oriented 
matching to determine which services support the dienfs 
requested Java interface. Both Jini and SLP use attributes to 
find services that match the dienfs requirements, but where 
SLP uses string-based attributes and weak typing, Jini 
employs Java objects throughout. 

Service discovery with SLP returns a URL denoting a ser- 
vice's location. Jini, on ihe other hand, returns an object that 
offers direct access to the service, using an interface known 
to the client. 

For some embedded systems that offer network services, 
running a Java Virtual Machine may require memory and 



processing resources fiat are too costly, thus precluding the 
use of Jini to advertise services. In those coses, SLP can 
advertise ihe services as well as a "Java Driver Factory * A 
Java Driver Factory is a dass (hat con be used to produce 
(instantiate and initialize) Java objects based upon initial- 
ization parameters. An SIP -Jini bridge can detect services 
and obtain their attributes and Java Driver Factory. (For 
more, see http://www.srvloc.org) The bridge uses the Java 
Driver Factory to instantiate a Java driver object, initializing 
it with the attributes advertised using SIP. TV* bridge then 
registers the service with a Jini Lookup server. 

When a Jini client discovers a service, it will be able to 
use it equally well, regardless of whether it was directly reg- 
istered with the Jini Lookup Server or registered by proxy 
via an SLP -Jini bridge. The bridge allows clients to moke 
use of Jini's powerful API to discover services on the net- 
work that cannot support Jini natively themselves. 
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As an additional level of authentication, DAs 
can also include digital signatures wick their adver- 
tisements. UAs and SAs can thus avoid DAs that 
have not been legitimately established by the sites 
administration because SLP agents that possess pri- 
vate keys for generating verifiable digital signatures 
are (by definition) trusted co legitimately advertise 
themselves. 

Security Configuration Requirements. SLP is 

designed to automatically configure service loca- 
tions with minimal static configuration require- 
ments for SLP agents. SLP security, however, does 



require some additional configuration (for the cryp- 
tographic keys or certificates used in generating and 
verifying digital signatures). 

When needed, vendors of SLP-enabled clients 
and services can establish new cryptographic algo- 
rithms and data formats within SLP's existing pro- 
tocol. It is also possible to deploy new keys gradu- 
ally, without requiring flag days, which would 
require simultaneous reconfiguration of all interop- 
erating systems. Suppose, for example, that corpo- 
rate policy requires that old private keys for authen- 
ticating servers be replaced in all SAs in the 
enterprise every three months. If flag days were 
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required, all SAs, UA.% and DAs would have to be 
rekeyed at once. SLR on the other hand, allows 
phasing in of new keys. SAs include digital signa- 
tures generated by both the new and old keys with 
their messages until all UAs and DAs replace the old 
keys, at which point, they phase out the old gener- 
ation of keys. 

Extensibility 

SLP extensions are additional protocol elements 
appended to messages. For example, there is an 
extension for reporting when a service request omits 
an attribute that is defined as required by a Service 
Template* Another extension eurrendy under devel- 
opment would allow UAs to request notification of 
additional services as they appear on the network. 

When an SLP agent recognizes a message exten- 
sion, it will perform the appropriate processing. If 
the extension is nor recognized, it is either ignored 
or the entire SLP message is discarded, depending 
on how the message extension is labeled. 

SLPs extensibility allows for future enhance- 
ments — such as additional error reporting added 
notification facility, and so on — without altering 
the base protocol. 

Browsing Features 

In addition to its required features, the SLP speci- 
fication describes several optional features that 
could be used to support sophisticated service 
browsers. 

Service Type Request. Using this type of message, 
UAs can discover all service types available on oSe 
network. The response supplies a top-level taxon- 
omy of services, which supports the basic require- 
ments for building a general ^service browser* on 
top of SLP. 

Attribute Request. A UA can use the Attribute 
Request to retrieve all the attributes of a given ser- 
vice in a manner similar to a directory lookup oper- 
ation. The UA can also issue the request without 
naming a specific service instance. The response 
from the DA (or SAs if there is no DA) returns all 
attributes and values for the requested service type 
within the network. For example, an Attribute 
Request for all available video servers on the net- 
work might return the following properties: 

■ locations include my building and a remote 
office; 

■ video streams include programs A and B. 



Table 2, SIP hoooW fields. 
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Version 
Length 
Function ID 
Flogs 

Next Extension 

Offset 
XJD 

Length 
Language log 



Description 

SLP protocol version: 1 and 2 ore defined. 
Length of the entire SLP message. 
Message type mat follow* the SLP Header. 
Indicate special treatment of the message. 

Offset, in bytes, to the first SLP Extension. 
Unique number tor each unique request. 

Length of the Language Tog that follows. 
Indicates the language of all human -readable 
strings included in the SLP message. 



Table 3. SIP messooe types and descriptions. 
SLP Message Type ID Description 



Service Request 
Service Reply 
Service Register 
Service Deregister 



Attribute Request 
Attribute Reply 
DAAoWr 

Service Type Request 
Service Type Reply 

SAAoWrt 



1 UAs find service by type, scope, and 
search filter. 

2 DA (or SA) returns Service URLs ood 
their lifetimes. 

3 SAs register Service URLs and attri- 
butes. 

4 SAs oeregister Service UftLs and 
attributes. 

Service AcluiowteagmentS DAs acknowledge a successful reg- 
istration or deregulation. 

6 UAs find attributes by service type or 
by Service URL 

7 DA (or SA) returns attribute infor- 
mation. 

8 DA sends its Service URL, scope, and 
attributes. 

9 UAs find service types by scope. 

10 DA (or SA) returns a list of service 
types. 

1 1 SA sends its Service URL, scope, and 
attributes. 



With chis information, a browser interface could 
help mc determine the location of a video server in 
my building or a video server that serves video 
srream A. If, however, I request a server that is in 
my building and serves video stream A, I might not 
succeed because the attributes are independent: 
video stream A might only be available from the 
server in the remote office. 

Attribute Request messages are also useful for 
determining the attributes of a particular service. 
The UA locates the corresponding Service URL, 
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and the Attribute Requesr. uses it to look up the 
fcr vice's attributes. Network software could also 
discover a particular services features by request- 
ing the attributes directly, which would require 
subsequent protocol feature negotiation between 
client and server. 

5 LP Operation over IPv6 

The formal specification has not yet been stan- 
dardized, but SLP is designed to provide service dis- 
covery facilities that will work for networks using 
IPv6. 11 Once the debate is settled regarding which 
string representation to use in URLs for numerical 
IPv6 addresses, some minor changes will be needed. 
Service URLs 5 containing numerical addresses will 
require a different format from what IPv4 uses, and 
link- local addresses will require some special han- 
dling in IPv6. For example, DAs that obtain service 
registrations with link-local numerical addresses 
must not forward them using the link on which 
they were registered. Also, the address to use for 
site-local scoped multicast operations differs in 
IPv4 from what it is in IPv6. 12 

SUMMARY 

SLP is an IETF standard for service discovery and 
automatic configuration of clients. It provides for 
fully decentralized operation and scales from a 
small, unadministered network to an enterprise 
network where policy may dictate who should dis- 
cover which resources. This paper describes how 
SLP operates and how it adapts to conditions where 
infrastructure is not available, where administra- 
tion is minimized, and where network administra- 
tors in large enterprises wish to reduce tedium and 
workload. While alternative mechanisms exist, SLP 
remains the most general and versatile solution for 
service discovery on TCP/IP networks. ■ 
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